Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds support for v1 compatible binary names in the bundler #1

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

krlvi
Copy link
Member

@krlvi krlvi commented Sep 7, 2024

🚧 Work in progress abandoned 🚧
👉 This task was picked up in tauri-apps#10938

This allows users of a Tauri v1 application to be able to smoothly update to a Tauri v2 application via the updater.

Background:

This change in Tauri https://github.com/tauri-apps/tauri/pull/9375/files, which is noted as a refactor is in fact a breaking change as far as the app updater is concerned.

The impact is that because the binary now has a different name, it is not possible to smoothly update a Tauri application via the updater if the initial version of the app is using v1.x and the new version is using v2.x.

Related upstream issues

tauri-apps#10548
tauri-apps/tauri-docs#2523 (docs)

Approach:

I'm introducing here an option for the tauri-cli (tauri-bundler) for producing the same binary names it did in v1, allowing users to update the app via the updater. In order to enable this behavior, set the environment varible

V1_COMPATIBLE_BIN_NAME=true

Previously, the bundler did the rename just after building the binary. I poked and tried doing the same once again, but because quite a lot of the code in that bundler changed since that was merged, it felt possibly more error prone (since now the rest of the code can safely assume that the binary is the crate name)

So, instead, my approach is to do the rename the binary at the last moment (i.e. in the bundle_project function in eg. app.rs)

Steps:

  • Introduce an env variable to enable the v1 behavior
  • Support the v1 renaming behavior for:
  • MacOS
  • Windows MSI
  • Windows NSIS
  • Debian
  • Fedora
  • AppImage
  • Tests?

This allows for updating at tauri v1 to v2 via the updater
@krlvi
Copy link
Member Author

krlvi commented Sep 7, 2024

Hi @lucasfernog, I wanted to check with you, is this change something that we would be able to upstream in Tauri (when ready) or are there some other plans?

@lucasfernog
Copy link

absolutely, I asked Amr to take a look at this specific issue next week

@krlvi
Copy link
Member Author

krlvi commented Sep 9, 2024

Okay just as an FYI, I have put development of this PR on hold because I have realized I don't have a good way of testing the Linux bundles myself

@Geometrically
Copy link

Geometrically commented Sep 10, 2024

Hey, since this issue is affecting our desktop app in production, I went ahead and finished it using yours as a base :) Here is the PR:
tauri-apps#10938

@krlvi
Copy link
Member Author

krlvi commented Sep 10, 2024

Hey, since this issue is affecting our desktop app in production, I went ahead and finished it using yours as a base :) Here is the PR: tauri-apps#10938

Thank you for picking this up, @Geometrically <3

@amrbashir
Copy link

Hello, and thanks for your patience. Over the past week, we have landed a few fixes and features to v2 and v1 to help fix migration issues between v1 updater and v2 updater plugin.

We strongly recommend that you update your app to latest tauri 1.8 and release a patch to your users, afterwards you can migrate to v2 updater plugin without a problem. tldr; <= 1.7 -> 1.8 -> 2.0.

Here is some links to the PRs:

@ndom91
Copy link

ndom91 commented Sep 17, 2024

@amrbashir thanks a lot for all of the work!

@krlvi I've got a PR open bumping to 1.8.0 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants